The applications on mobiles have undergone a significant expansion in recent years, which has contributed to the explosion of the quantity of data exchanged between the mobile terminals and the mobile communication networks, as well as the quantity of signaling messages exchanged over these networks.
The new generation of applications on mobiles, called “mobile web applications”, relies on the use of a user agent installed on a mobile terminal (typically a web browser) used to control a web application installed on a remote web server, via a mobile telecommunications access network and the Internet network.
This new generation of mobile web applications, through its decentralized and interactive nature, risks further increasing the phenomenon of growth of the quantity of data and of signaling messages exchanged over the network. In particular, the management of the notifications by these mobile web applications, imported from the practices of the conventional “web” applications in the fixed networks, is not suited to a mobile environment.
Thus, the use of http requests for the notification, for example for so-called “http polling” or “textstreams” techniques, between the mobile terminal and the web server is not optimal, because these http requests generally generate a large number of “keep-alive” http messages in order to check whether the radio link is still set up with the network, which requires a data radio link, in the form of a dedicated transport channel DCH, which has to be re-established each time a notification is sent, and therefore generate the consumption of a large quantity of radio resources.
Furthermore, so-called “fast dormancy” functions have been implemented in certain mobile telephones in order to save on the batteries of the mobile telephones. With this type of function, the establishment of a data radio link channel becomes lengthy and costly, both in terms of battery energy consumption and of signaling on the network, which is not compatible with the multiplication of the notification messages brought about by the expansion of the mobile web applications.
A technical implementation of “Push API” type, consisting in introducing a “push” proxy server into the network, has been proposed in the downlink direction, that is to say from the web server to the mobile terminals. See http://dvcs.w3.org/hg/push/raw-file/default/index.html
In this technical implementation, a “push” proxy server is introduced into the network of the operator, between the mobile terminal and the web server. The web server can send to this “push” proxy server a “push” message intended for the web application installed on the mobile terminal TE, this “push” message being defined according to a particular service programming interface (API). The “push” proxy server will then convert this “push” message into a new “push” message according to a particular service protocol, and transmit this new “push” message to the mobile terminal TE where it will be analyzed.
Such a solution is however limited to just the downlink direction and does not address the issue of the increase in the signaling in the uplink direction, from the mobile terminal on which the user agent is installed to the web server.